Queuing Approach

The Queue Engine component represents Orchestra's process flow layer. It is based on the assumption that a system, such as Orchestra, should have a defined and scalable resource consumption. To this effect, the "Queues" concept is introduced. Queues collect the tasks to be performed (WorkItems). A pool of threads (WorkProcessor) is assigned to each queue that accepts individual entries and processes them. Whenever a subsystem has some work that needs to be executed, it creates a workitem that is put to the queue engine. The queue engine executes the workitem when a free WorkProcessor-Thread is available. When the work is done, the owner is informed and can execute further workitem.

Within Orchestra, there is a distinction between two types of Queues.

• Volatile queues are typically used with online interfaces and when high performance is required. This characteristic is achieved by storing WorkItems in the main memory. This reduces the overhead to a minimum but in case of a system crash the current system state is lost and it is not possible to recover the last queue state.

• Persistent queues are used for asynchronous, batch-oriented interfaces. Within one of such scenarios, the focus lies on a robust and reliable mode of operation. This is achieved by storing individual WorkItems in persistent memory. As a result, Orchestra can correctly restart even in the event of a system failure.

Beside the fact that queues can be volatile or persistent Orchestra implements the queues of type fifo and best effort. Fifo queues ensure that workitems are processed in the order as they are added to the queue. Due to this requirement a fifo queue can execute only one workitem at a time. On the opposite, best effort queues try to execute as max workitems as possible in parallel.